Hey, I have few queries:

• There was no configuration file found for pokemon_v2_typesprites. Was it left out intentionally?
• Since I have set up these custom names, the old pokemon_v2_ prefix won't work in our GraphQL queries anymore. This definitely affects backward compatibility for any existing clients. Is this acceptable, especially since we're currently in a beta version?

Hi!

1. I think we didn't update the schema. So feel free to add the schema here or to open another PR for it.

2. We need to think about it. I'm ok with not supporting anymore the prefix and adding beforehand a banner on the website stating the change. Ideally though it would be perfect to support both schemas. Even with a duplication of code. Do you think it is feasible?

Btw, thanks a lot for working on this!

Hey!

Hasura's custom_name works by replacing the default GraphQL name. It doesn't create an alias or expose both the original pokemon_v2_tablename and the tablename simulltaneously.

So, I think It is best to stop supporting the prefix entirely. Because, If we want to support both versions, there are some complex ways to achieve it like maintaining two hasura instances or setting up a gateway/proxy to translate the old queries to new one. I think removing the prefix entirely is the most simple and feasible solution.

What are your thoughts on this??

I have another query regarding how a "v2 to v3" API transition will affect our database tables.

Would it involve renaming all existing tables, for example, from pokemon_v2_move to pokemon_v3_move? Or keeping the v2 tables as it is like pokemon_v2_move and adding the new tables as v3 tables like pokemon_v3_foo.

If we rename all existing tables, we need to also reconfigure our hasura.

Honesty @PraaneshSelvaraj I don't think we will ever have a v3 version of the API. No one has the time/will to work on it.

I was actually thinking that maybe in future we could use the GraphQL endpoint as v3. We could just change the logic of how pokemons, species, varieties, forms are mapped into files, and in postgres and then offer the Hasura GQL on top of that data. Without writing Django code. That will shave off some work.

And I thought about dropping support for the pokemon_v2_* prefix, I'd actually like to support both for a limited time. I can set up another machine with another endpoint, maybe https://beta.pokeapi.co/graphql/v1beta2. So I'm ok duplicating the code or the entire folder for the time being.

Hey @Naramsim, If we want to support both for limited time, we can do it by

• Option 1: Keep the existing Hasura instance from the master branch (with the pokemon_v2_ prefixes), and deploy a second Hasura instance from this new branch (without the prefixes).

• Option 2: Within the same repo, create a second metadata directory (e.g., graphql_deprecated or graphql_v1beta1) that contains the Hasura config with the prefixes. Each Hasura deployment can then load metadata from its respective directory using the Hasura CLI.

Personally, I think Option 1 makes more sense if this is only temporary. We can notify clients and encourage them to switch to the new version over time.
Option 2 feels more appropriate if we intend to run both versions side-by-side long-term.

So, What should we do now or do you have a different strategy in mind?

Hey @Naramsim,

I updated the branch with these changes:

1. Indentation is fixed.
2. pokemonV2 prefixes are removed.
3. The typesprites table is now tracked.

I have also force-pushed this branch to clean up the commit history.

Please check it out when you get a chance.

Hi! @PraaneshSelvaraj @phalt , could you try play a bit here with the prefix stripped?

PS: amazing work @PraaneshSelvaraj !

If you agree we could expose this version as default! And let the other running in background, after some URL tweaks

A thought, we could even hide all the *_by_pk entries from the explorer page. They are a bit faster than the standard query with a where clause but maybe they are cluttering up a bit too much all the options in the explorer page. And with GQL not many people will use the ID of a resource to fetch it, rather they'll use its name

Could you clarify if hiding _by_pk entries in the Hasura Console is a setting that affects only the admin's view in the explorer, or if it's a global change that applies to all roles, such as anon, when they query the GraphQL API?

Could you clarify if hiding _by_pk entries in the Hasura Console is a setting that affects only the admin's view in the explorer, or if it's a global change that applies to all roles, such as anon, when they query the GraphQL API?

I honestly don't know. I think we can hide them globally in a way that those endpoints cannot be used.

Or maybe I can hide them with CSS to have less clutter

I think it is best to remove the select_by_pk entierly. It makes more sense for users to query by actual fields like name rather than internal primary keys.

If that's good with you, I will try to remove them.

Ok! Go along and try to do it! Thanks again!

Hey @Naramsim,

I have removed the select_by_pk root fields for the anon role. Now, clients will no longer see these select_by_pk fields in the explorer or use them in their queries.

As shown in the attached Postman screenshot, these fields are no longer present.

Hi! I deployed it here! https://graphql.pokeapi.co/v1beta2/console/

I think we are ready to update the docs and to suggest people to use the new endpoint! What do you think about the new URL?

Something like: https://staging.pokeapi.co/docs/graphql

Hey @Naramsim,

I think the new URL, https://graphql.pokeapi.co/v1beta2/console/, is excellent. The graphql subdomain clearly states its purpose, and the /v1beta2/ path provides great clarity for versioning.

I do have one query about the documentation at https://staging.pokeapi.co/docs/graphql. Currently, there is no direct link to v1beta1 GraphiQL interface. Even though we are planning its removal, I think it would be best to include the link until its removal, so that the user can easily navigate it.

What are your thoughts on this?

I added a link to the current console. Should be up in minutes. When we merge this then, I'll need to add a banner on the current/old console stating the deprecation. And I should also configure the GH action to update the data on the new GQL VM as well.

I think, you should also add "Going to be deprecated" banner on the current v1beta1 GraphiQL interface. That way, users who are still there will get the message directly.

Yes but only when we will merge the PR

I moved the PR over here: #1264

So that I can work on it! Your commits are preserved!

Hi @PraaneshSelvaraj I merged the PR! I made some changes afterwards but the code is now online!

Many thanks for everything!